POUR PDF - copie

ion Techniques: model-checking raised interest in techniques to abstract infinite to finite models. Provided that the abstraction has been proven sound, testing may be sufficient for establishing correctness [10, 18]. Systematic Testing: the discussion over test adequacy criteria [27], i. e. criteria solving the question “when did we test enough to meet a given test hypothesis,” led to more systematic approaches for partitioning the space of possible test data and the choice of representatives. New systematic testing methods and abstraction techniques can be found in [22, 20]. Specification Animation: constructing counter-examples has raised interest also in the theorem proving community, since combined with animations of evaluations, they may help to find modeling errors early and to increase the overall productivity [9, 23, 17]. The first two areas are motivated by the question “are we building the program right?” the latter is focused on the question “are we specifying the right program?” While the first area shows that Dijkstra’s Verdict is no longer true under all circumstances, the latter area shows, that it simply does not apply in practically important situations. In particular, if a formal model of the environment of a software system (e. g. based among others on the operation system, middleware or external libraries) must be reverseengineered, testing (“experimenting”) is without alternative (see [12]). Following standard terminology [27], our approach is a specification-based unit test . In general, a test procedure for such an approach can be divided into: Test Case Generation: for each operation the pre/postcondition relation is divided into sub-relations. It assumes that all members of a sub-relation lead to a similar behavior of the implementation.